Tracking assets with a blockchain

ABSTRACT

A blockchain of transactions may be referenced for various purposes and may be later accessed by interested parties for ledger verification. One example method of operation may include reading a tag affixed to an asset, transmitting a request to update an asset status of the asset in a blockchain, receiving validation confirmation based on content of the request, and updating the asset status of the asset in the blockchain.

TECHNICAL FIELD

This application relates to tracking assets, and more particularly, totracking assets with a blockchain.

BACKGROUND

The blockchain may be used as a public ledger to store information.Although, primarily used for financial transactions, the blockchain canstore information including assets (i.e., products, packages, services,etc.). The blockchain may be used to establish ownership, provenance, ahistorical record of status, state, location changes, etc. In operation,tracked assets may include a serial number used to uniquely identifyeach specific item and that serial number may naturally be a keyidentifier used in the ledger. However, there may still be fraud ormisuse of the ledger when tracking ledger updates for a particularasset. For example, while determining whether a particular sourceactually has possession of the asset, a fraudulent attempt to controlthe asset may be submitted from a source that merely has knowledge ofthe asset's serial number.

SUMMARY

One example embodiment may include a method that comprises one or moreof reading a tag affixed to an asset, transmitting a request to updatean asset status of the asset in a blockchain, receiving validationconfirmation based on content of the request, and updating the assetstatus of the asset in the blockchain.

Another example embodiment may include an apparatus that includes one ormore of a processor configured to read a tag affixed to an asset, atransmitter configured to transmit a request to update an asset statusof the asset in a blockchain, and a receiver configured to receivevalidation confirmation based on content of the request, and theprocessor is further configured to update the asset status of the assetin the blockchain.

Still another example embodiment may include a non-transitory computerreadable storage medium configured to store instructions that whenexecuted cause one or more of reading a tag affixed to an asset,transmitting a request to update an asset status of the asset in ablockchain, receiving validation confirmation based on content of therequest, and updating the asset status of the asset in the blockchain.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an asset identification and update operation using ablockchain according to example embodiments.

FIG. 2 illustrates an example system signaling configuration platformfor updating asset status in the blockchain according to exampleembodiments.

FIG. 3A illustrates a flow diagram of an example method of authorizingand updating assets in the blockchain according to example embodiments.

FIG. 3B illustrates a flow diagram of another example method ofauthorizing and updating assets in the blockchain according to exampleembodiments.

FIG. 4 illustrates an example network entity configured to support oneor more of the example embodiments.

DETAILED DESCRIPTION

It will be readily understood that the instant components, as generallydescribed and illustrated in the figures herein, may be arranged anddesigned in a wide variety of different configurations. Thus, thefollowing detailed description of the embodiments of at least one of amethod, apparatus, non-transitory computer readable medium and system,as represented in the attached figures, is not intended to limit thescope of the application as claimed, but is merely representative ofselected embodiments.

The instant features, structures, or characteristics as describedthroughout this specification may be combined in any suitable manner inone or more embodiments. For example, the usage of the phrases “exampleembodiments”, “some embodiments”, or other similar language, throughoutthis specification refers to the fact that a particular feature,structure, or characteristic described in connection with the embodimentmay be included in at least one embodiment. Thus, appearances of thephrases “example embodiments”, “in some embodiments”, “in otherembodiments”, or other similar language, throughout this specificationdo not necessarily all refer to the same group of embodiments, and thedescribed features, structures, or characteristics may be combined inany suitable manner in one or more embodiments.

In addition, while the term “message” may have been used in thedescription of embodiments, the application may be applied to many typesof network data, such as, packet, frame, datagram, etc. The term“message” also includes packet, frame, datagram, and any equivalentsthereof. Furthermore, while certain types of messages and signaling maybe depicted in exemplary embodiments they are not limited to a certaintype of message, and the application is not limited to a certain type ofsignaling.

Example embodiments provide storing asset information in a blockchain,to storing asset status information in a blockchain and requiringcertain security measures prior to permitting asset statusmodifications. Further embodiments include using a blockchain publicledger to track assets. Assets may be shipments, products, devices,multiple products, etc. The tracked assets may be identified by a serialnumber or product identifier (ID) that is used to uniquely identify eachspecific asset. The serial number can be the main identifier used in theledger when determining if a ledger update for a particular asset isfrom a source that actually has possession of the asset. The identifiermay be mismanaged by a source that merely has knowledge of the asset'sserial number and which is trying to modify/hack/control the assetstatus remotely based on the serial number. By using serializationtechnology, such as RFID tags or other wireless tags, which includereadable and writable memory, the security and authorization is able toread and write to the tag. This process may include a user memoryreading a permanent serial number from the tag and a nonce. The noncemay be a random or pseudo-random number that may only be used once toperform a blockchain transaction.

By including a memory portion of the tag, an identifier and a secret orlimited knowledge measure may also be included to provide a second levelof validation to ensure that a person attempting a ledger updateactually has the asset in their possession and is able to extract thedynamic variable, which in this example is a dynamic nonce. This dynamicnonce, which was updated the last time the asset was identified in ashipment chain, custody chain, or other transfer of ownership orsupervision type chain, is configured to periodically scan theidentifier information on the wireless or RFID tag affixed to the assetand update a central tracking system with product shipment information.When the nonce is identified from the RFID tag and an asset updateoccurs in the blockchain, the nonce that is written to the tag afterevery ledger update is an updated nonce which is unique, new and has notbeen used to add asset data to the blockchain. Any attempted update tothe ledger is required to produce an expected nonce value that isidentified from the RFID tag and which is known to the blockchain data.If found to be valid, the next expected nonce value will be updated inthe blockchain and in the RFID tag so an entity that identifies theproduct ID may not have access to the latest nonce stored in the RFIDand in the blockchain during a previous asset log operation. Inoperation, the new nonce is arbitrarily assigned by the reader deviceafter an update to the blockchain.

FIG. 1 illustrates an asset identification and update operation 100using a blockchain according to example embodiments. Referring to FIG.1, the asset 110 may be a box, crate, product, etc., and the tag 112,may be a wireless tag with one or more of a processor, a memory, areceiver, a transceiver, and a transceiver. The tag may be a RFID tagthat is affixed to the asset 110 via a stick adhesive, magnet or otheraffixing mechanism. In other embodiments, the tag 112 may be integratedin the body of the asset 110. The tag 112 may include radiocommunication functions 114 along with a memory 116 that is capable ofstoring product ID information, nonce data, and other data. Inoperation, a RF device 120 or reader may be in communication with acomputer system (not shown) which can communicate with a blockchain orother data storage systems. When a product is dispatched from a location(such as a factory), received at another location (such as a shippingfacility), dispatched to a driver, etc., the product/asset and the assetstatus may be updated in the blockchain for an immutable record of theasset's existence and updated existence.

The tag memory 116 may contain a nonce value or an empty nonce value ifthe asset has never been updated (prior to first update). A nonce is arandom or pseudo-random number that may only be used once when hashing ablockchain entry for finalization. The reader 120 may scan the tag 112and extract the product ID 132, the nonce value 134 and otherapplication ledger data 136 which is partially or wholly extracted fromthe asset 110 or which is substituted from other information sources tocomplement the asset data when storing the data in the blockchain.Information may include time, number of transactions, assetspecification data, blockchain related information, etc.

An assigned serial number can be read from the tag and “user memory”which permits for updateable data to be written to the tag. With thisapproach, a nonce can be included in the user memory portion 116 of thetag 112 that will provide a second level validation to ensure that aperson attempting a ledger update actually does have the asset in theirpossession and has the serial number and the current nonce value thatmatches the current nonce value stored in the blockchain, which isdynamically assigned and re-assigned. The nonce that is written to thetag is dynamically updated after every ledger update. The ledger of theblockchain then becomes a validation source for any attempted update tothe ledger which includes the expected nonce value which is also storedin the ledger.

In this example, a ledger update may include various pieces ofinformation as validators including the serial number of the tag, whichis the asset ID read from the tag, the nonce value read from the tag,and a newly updated nonce value, which is the new nonce value that willbe updated on the tag once the previous nonce value is used to validatethe blockchain transaction. For standard usages and tracking, an updateto the ledger may be performed to identify where an item is with respectto the rest of the logistics chain. The update to the ledger could beperformed to establish a pedigree (i.e., anti-tampering) in a supplychain (i.e., provenance). The update could also be performed foroperational controls, such as establishing a transit time, dwell time,“cohort” analysis, etc.

With regard to issuing the new nonce, consider two portions ofidentifying information are needed to update a ledger. One is a serialnumber, which is fixed and could easily be “known” by various parties.The other is a rotating value (nonce) that changes at every transaction.The nonce is then be available with the object on its tag and is alsoknown to the ledger. In operation, the tag will be read to extract boththe serial number and the current nonce. A transaction update to theledger will be requested with those two pieces of information forvalidation. In addition, that transaction request will contain a “nextnonce” value that the ledger will maintain. The reader device willupdate the tag with the “next nonce” value. As such, when the tag isread at the next stop on its path, the process continues and the tag'sserial and nonce are read, sent to the ledger in a transaction to bevalidated along with a newly created “next nonce” value that will beupdated in the ledger and updated on the tag. The nonce value is foundto be valid when the one in the tag matches a same value in theblockchain.

The ledger can then determine for a given serial numbered tag if thenonce value that was provided in the ledger update request was theexpected nonce value by comparing that nonce value to the one stored inthe blockchain. Also, such a value could only be obtained from the tagitself. If the nonce value is found to be valid, the ledger will updateits next expected nonce value reference with the new nonce provided.This permits the next update request to go through the same validation.In order to protect against fraudulent absent-observation ledgerupdates, the two-factor identification mechanism for tag identificationreduces the chances of fraud. In this case, a tag is successfullyreference-able to the ledger using two pieces of information includingan assigned asset tag serial ID and a rotating identification key(nonce). The nonce is used to provide ‘originality’ to a given ledgerrequest against replay attacks and confederate systems attempting torecord tag observations by knowing only the tag serial number.

In one example, an asset is tracked at location ‘A’ with tag ‘T’. Thisis an initial tracking operation. At location ‘A’ an object with tag ‘T’is read, the read information from tag ‘T’ contains tag ID, for example,“12345678” and nonce: <blank>. Location A (reader device, server, etc.)generates a new random number nonce, for example, “858469071245” to beused as the next nonce, and makes an update request to the ledger(blockchain) for object with tag ID “12345678”. In this example, thecurrent nonce is blank due to an initial asset identification andlogging operation of the RFID tag which has not yet been performed, andthen a next nonce is “858469071245”. Application specific informationfor the ledger is included as well as part of the ledger update. Theledger retrieves the latest reference for tag ID “12345678” and in thiscase the value is null or non-existent which indicates that this is thefirst entry attempt. No further validation is required. The ledger isupdated to include a reference for tag ID “12345678” which alsospecifies its next expected nonce value as “858469071245”. Applicationspecific information is also added to the ledger entry to identify theother transaction details. As a result, location ‘A’ updates tag T userinformation, setting the tags' nonce value to “858469071245”.

FIG. 2 illustrates an example system signaling configuration platformfor updating asset status in the blockchain according to exampleembodiments. Referring to FIG. 2, the system configuration 200 includesa tag 210 which is affixed to, near or integrated with the asset to bemonitored. The reader device or location site (such as a server) 220which is part of the location where the asset/tag are currently locatedand the blockchain 230 are other entities of the example system 200. Theblockchain 230 may be stored on a device with a processor and memory. Inthis example, the store product ID 212 is assigned to the asset andstored in the memory of the tag 210. The asset and tag may betransported to a new waypoint location and the reader device/locationsite 220 may initiate a tag reading operation 214. The tag reader 220may retrieve the tag information and any previous nonce values stored inthe tag 210. The tag reader may be a wireless access device thatreceives RF signals from the tag. The reader 220 may generate a newnonce 216 at some point during the communication session with the tagand the blockchain 230. The retrieved tag information is forwarded tothe blockchain 230 along with any retrieved nonce values stored in thetag. The information is forwarded as a request 218 and as a result, theblockchain 230 may retrieve any asset information previously stored forthe product ID provided 222 and also determine whether the nonce existsor if this is a first update 224. The status information of the asset isupdated 226 with the new nonce value created during this assettransaction. The tag update 228 can be made to include the new noncevalue now that the previous one is obsolete or now that one has beenassigned in the case of a first transaction update to the tag. The noncevalue is sent to the tag 232 and stored in the tag 210.

In another example, an asset is tracked at another location ‘B’ with tag‘T’. The location ‘B’ reader may read tag ‘T’. In this example, thecontent of the tag will include a previously assigned nonce since thisis not the first transaction as in the example with location ‘A’. Theinformation read from tag ‘T’ may include tag ID: “12345678” and nonce:“858469071245”. The location ‘B’ device may generate a new randomnumber, “026254866907” to be used as the next nonce after thistransaction with the previous nonce is complete. Location ‘B’ may makean update request to the ledger for the object/asset with tag ID“12345678”, and with a current nonce as “858469071245”, and the nextnonce will be “026254866907” which replaces the previous nonce value.Application specific information for the ledger is included as well inthe request to the ledger for the update. The ledger may retrieve alatest reference for tag ID: “12345678” and determine that the lastentry has a private data entry for the next expected nonce with thevalue “858469071245”. The update request includes this same value as thecurrent nonce from the tag read operation so the ledger update requestis validated. The ledger is updated to include a new reference for tagID “12345678” and specifies its next expected nonce value as“026254866907”. Application specific information is also added to theledger entry. For example, location ‘B’ updates tag T user informationwhich sets the tag nonce value to “026254866907”. Application specificinformation may include a supply chain, an e-pedigree forpharmaceuticals, ownership/provenance for high value items, and generallocation tracking use cases.

FIG. 3A illustrates a flow diagram 300 of an example method ofauthorizing and updating assets in the blockchain according to exampleembodiments. Referring to FIG. 3A, the method may include one or more ofreading a tag affixed to an asset 312, transmitting a request to updatean asset status of the asset in a blockchain 314, receiving validationconfirmation based on request content 316 and updating the asset statusof the asset in the blockchain 318. The request content may include oneor more of a tag identifier, a nonce value stored in the tag and a newnonce value for a subsequent update to the blockchain. The validationconfirmation is received responsive to transmitting the tag identifierand the nonce value as the request content. The tag may include a radiofrequency identification (RFID) component and a memory. The memorystores the tag identifier and a nonce value. An initial value of thenonce value stored in the memory is blank/null prior to any update tothe asset status in the blockchain, however, after the asset status ofthe asset is updated in the blockchain, the method may also includeupdating the memory to store a new nonce value.

FIG. 3B illustrates a flow diagram 350 of another example method ofauthorizing and updating assets in the blockchain according to exampleembodiments. Referring to FIG. 3B, the method 350 may include one ormore of reading a tag affixed to an asset 352, transmitting a request toupdate an asset status of the asset in a blockchain, wherein the requestcomprises a history of address tag locations associated with the tag354, receiving validation confirmation based on the history of addresstag locations included in the request and the blockchain 356, andupdating the asset status of the asset in the blockchain 358. Thisalternative approach includes identifying a history of locationinformation stored in the tag and the blockchain as an added securitymeasure necessary prior to receiving access to write and update assetstatus in the blockchain. If the locations stored in the tag are thesame as those stored in the blockchain, the access will be grantedpending other security requirements. The locations may be logged eachtime the RFID tag is scanned, read, accessed at any location. Thelocations may be added each time to create a list of locationscorresponding to the information in the blockchain.

The above embodiments may be implemented in hardware, in a computerprogram executed by a processor, in firmware, or in a combination of theabove. A computer program may be embodied on a computer readable medium,such as a storage medium. For example, a computer program may reside inrandom access memory (“RAM”), flash memory, read-only memory (“ROM”),erasable programmable read-only memory (“EPROM”), electrically erasableprogrammable read-only memory (“EEPROM”), registers, hard disk, aremovable disk, a compact disk read-only memory (“CD-ROM”), or any otherform of storage medium known in the art.

An exemplary storage medium may be coupled to the processor such thatthe processor may read information from, and write information to, thestorage medium. In the alternative, the storage medium may be integralto the processor. The processor and the storage medium may reside in anapplication specific integrated circuit (“ASIC”). In the alternative,the processor and the storage medium may reside as discrete components.For example, FIG. 4 illustrates an example network element 400, whichmay represent or be integrated in any of the above-described components,etc.

As illustrated in FIG. 4, a memory 410 and a processor 420 may bediscrete components of a network entity 400 that are used to execute anapplication or set of operations as described herein. The applicationmay be coded in software in a computer language understood by theprocessor 420, and stored in a computer readable medium, such as, amemory 410. The computer readable medium may be a non-transitorycomputer readable medium that includes tangible hardware components,such as memory, that can store software. Furthermore, a software module430 may be another discrete entity that is part of the network entity400, and which contains software instructions that may be executed bythe processor 420 to effectuate one or more of the functions describedherein. In addition to the above noted components of the network entity400, the network entity 400 may also have a transmitter and receiverpair configured to receive and transmit communication signals (notshown).

Although an exemplary embodiment of at least one of a system, method,and non-transitory computer readable medium has been illustrated in theaccompanied drawings and described in the foregoing detaileddescription, it will be understood that the application is not limitedto the embodiments disclosed, but is capable of numerous rearrangements,modifications, and substitutions as set forth and defined by thefollowing claims. For example, the capabilities of the system of thevarious figures can be performed by one or more of the modules orcomponents described herein or in a distributed architecture and mayinclude a transmitter, receiver or pair of both. For example, all orpart of the functionality performed by the individual modules, may beperformed by one or more of these modules. Further, the functionalitydescribed herein may be performed at various times and in relation tovarious events, internal or external to the modules or components. Also,the information sent between various modules can be sent between themodules via at least one of: a data network, the Internet, a voicenetwork, an Internet Protocol network, a wireless device, a wired deviceand/or via plurality of protocols. Also, the messages sent or receivedby any of the modules may be sent or received directly and/or via one ormore of the other modules.

One skilled in the art will appreciate that a “system” could be embodiedas a personal computer, a server, a console, a personal digitalassistant (PDA), a cell phone, a tablet computing device, a smartphoneor any other suitable computing device, or combination of devices.Presenting the above-described functions as being performed by a“system” is not intended to limit the scope of the present applicationin any way, but is intended to provide one example of many embodiments.Indeed, methods, systems and apparatuses disclosed herein may beimplemented in localized and distributed forms consistent with computingtechnology.

It should be noted that some of the system features described in thisspecification have been presented as modules, in order to moreparticularly emphasize their implementation independence. For example, amodule may be implemented as a hardware circuit comprising custom verylarge scale integration (VLSI) circuits or gate arrays, off-the-shelfsemiconductors such as logic chips, transistors, or other discretecomponents. A module may also be implemented in programmable hardwaredevices such as field programmable gate arrays, programmable arraylogic, programmable logic devices, graphics processing units, or thelike.

A module may also be at least partially implemented in software forexecution by various types of processors. An identified unit ofexecutable code may, for instance, comprise one or more physical orlogical blocks of computer instructions that may, for instance, beorganized as an object, procedure, or function. Nevertheless, theexecutables of an identified module need not be physically locatedtogether, but may comprise disparate instructions stored in differentlocations which, when joined logically together, comprise the module andachieve the stated purpose for the module. Further, modules may bestored on a computer-readable medium, which may be, for instance, a harddisk drive, flash device, random access memory (RAM), tape, or any othersuch medium used to store data.

Indeed, a module of executable code could be a single instruction, ormany instructions, and may even be distributed over several differentcode segments, among different programs, and across several memorydevices. Similarly, operational data may be identified and illustratedherein within modules, and may be embodied in any suitable form andorganized within any suitable type of data structure. The operationaldata may be collected as a single data set, or may be distributed overdifferent locations including over different storage devices, and mayexist, at least partially, merely as electronic signals on a system ornetwork.

It will be readily understood that the components of the application, asgenerally described and illustrated in the figures herein, may bearranged and designed in a wide variety of different configurations.Thus, the detailed description of the embodiments is not intended tolimit the scope of the application as claimed, but is merelyrepresentative of selected embodiments of the application.

One having ordinary skill in the art will readily understand that theabove may be practiced with steps in a different order, and/or withhardware elements in configurations that are different than those whichare disclosed. Therefore, although the application has been describedbased upon these preferred embodiments, it would be apparent to those ofskill in the art that certain modifications, variations, and alternativeconstructions would be apparent.

While preferred embodiments of the present application have beendescribed, it is to be understood that the embodiments described areillustrative only and the scope of the application is to be definedsolely by the appended claims when considered with a full range ofequivalents and modifications (e.g., protocols, hardware devices,software platforms etc.) thereto.

What is claimed is:
 1. A method, comprising: reading, via a reader incommunication with a blockchain, and from a tag affixed to an asset, atag identifier associated with the asset, and a nonce value associatedwith a current location of the asset, wherein the tag identifier and thenonce value are stored in the tag and in locations in the blockchain;generating, via the reader, a new nonce value associated with a transferof the asset to a new location, the new nonce value to be stored in alocation in the blockchain; and dynamically updating, via the reader,the tag with an updated asset status from the blockchain and the newnonce value from the blockchain in response to a request including thetag identifier, the nonce value, and the new nonce value.
 2. The methodof claim 1, comprising: transmitting, via the reader, the request toupdate the asset status, of the asset, stored in the blockchain; andreceiving, via the reader, and from the blockchain, a validationconfirmation based on the request.
 3. The method of claim 1, wherein thevalidation confirmation is received responsive to transmitting the tagidentifier and the nonce value as the request content.
 4. The method ofclaim 1, wherein the tag comprises a radio frequency identification(RFID) component and a memory.
 5. The method of claim 4, wherein thememory stores the tag identifier and the nonce value.
 6. The method ofclaim 5, wherein an initial value of the nonce value stored in thememory is blank prior to any update to the asset status in theblockchain.
 7. The method of claim 5, wherein after the asset status ofthe asset is updated in the blockchain, updating the memory to store thenew nonce value.
 8. A wireless tag reader, comprising: a processorconfigured to: read, via a reader in communication with a blockchain,and from a tag affixed to an asset, a tag identifier associated with theasset, and a nonce value associated with a current location of theasset, wherein the tag identifier and the nonce value are stored in thetag and in locations in the blockchain; generate, via the reader, a newnonce value associated with a transfer of the asset to a new location,the new nonce value to be stored in a location in the blockchain; anddynamically update, via the reader, the tag with an updated asset statusfrom the blockchain and the new nonce value from the blockchain inresponse to a request including the tag identifier, the nonce value, andthe new nonce value.
 9. The wireless tag reader of claim 8, wherein theprocessor is configured to: transmit, via the reader, the request toupdate the asset status, of the asset, stored in the blockchain; andreceive, via the reader, and from the blockchain, a validationconfirmation based on the request.
 10. The wireless tag reader of claim8, wherein the validation confirmation is received responsive to the tagidentifier being transmitted and the nonce value as the request content.11. The wireless tag reader of claim 8, wherein the tag comprises aradio frequency identification (RFID) component and a memory.
 12. Thewireless tag reader of claim 11, wherein the memory stores the tagidentifier and the nonce value.
 13. The wireless tag reader of claim 12,wherein an initial value of the nonce value stored in the memory isblank prior to any update to the asset status in the blockchain.
 14. Thewireless tag reader of claim 12, wherein after the asset status of theasset is updated in the blockchain, the memory is updated to store thenew nonce value.
 15. A non-transitory computer readable storage mediumconfigured to store at least one instruction that when executed by aprocessor, causes the processor to perform: reading, via a reader incommunication with a blockchain, and from a tag affixed to an asset, atag identifier associated with the asset, and a nonce value associatedwith a current location of the asset, wherein the tag identifier and thenonce value are stored in the tag and in locations in the blockchain;generating, via the reader, a new nonce value associated with a transferof the asset to a new location, the new nonce value to be stored in alocation in the blockchain; and dynamically updating, via the reader,the tag with an updated asset status from the blockchain and the newnonce value from the blockchain in response to a request including thetag identifier, the nonce value, and the new nonce value.
 16. Thenon-transitory computer readable storage medium of claim 15, wherein theprocessor is configured to perform: transmitting, via the reader, therequest to update the asset status, of the asset, stored in theblockchain; and receiving, via the reader, and from the blockchain, avalidation confirmation based on the request.
 17. The non-transitorycomputer readable storage medium of claim 15, wherein the validationconfirmation is received responsive to transmitting the tag identifierand the nonce value as the request content.
 18. The non-transitorycomputer readable storage medium of claim 15, wherein the tag comprisesa radio frequency identification (RFID) component and a memory.
 19. Thenon-transitory computer readable storage medium of claim 18, wherein thememory stores the tag identifier and the nonce value.
 20. Thenon-transitory computer readable storage medium of claim 19, wherein aninitial value of the nonce value stored in the memory is blank prior toany update to the asset status in the blockchain, and wherein after theasset status of the asset is updated in the blockchain, updating thememory to store the new nonce value.